一個人做產品，最怕的不是技術難，是「還沒收到一毛錢，帳單先來」。所以架構拍板那天，我先做了一張表：免費額度到底能撐到哪裡，以及撞到牆的時候會發生什麼事。

不把這張表算清楚，後面所有決定都是猜的。

三項免費額度，對照我的用法

為什麼這個架構有機會真的是 $0

關鍵在 R2 那一格的後半句：免流出費。

CDN 帳單裡最貴的一項通常是流出（egress）——內容越熱門、被讀越多次，帳單越貴。這是「受歡迎」要付的代價，聽起來很荒謬，但那就是傳統 CDN 的形狀。

而我的內容是「一次寫、很多次讀」的靜態 markdown，正是流量最兇的那種負載。如果流出要錢，這套架構從第一個使用者就開始付錢了。

還有一點：就算真的撞到 10GB，那付的是「儲存」的錢，不是「流量」的錢。這兩條成長曲線完全不一樣——儲存是線性的、可預測的；流量是會在你最開心（有人大量使用）的那天爆炸的。把不可預測的那一項換掉，是我選 R2 最實在的理由。

真正會先撞到的不是儲存，是請求數

D1 的 5GB 放的是索引，不是正文（正文在 R2），所以那條線很後面才會碰到。R2 的 10GB 同理。

最先撞到的是 Workers 的每天 10 萬個請求。 這個數字很好換算：如果我有一個使用者一天用 100 次，10 萬 ÷ 100 = 1,000 個活躍使用者。

看起來不多。但要記得，這是一個人做、還沒開始推廣的階段的量級——在我需要擔心這條線之前，我早就該開始收錢了。 這正是免費額度的意義：它不是商業模式，它是「讓我可以先做半年再決定」的緩衝。

兩個「上限」管的不是同一件事

這裡有個我一開始搞混、後來覺得值得寫出來的地方。

我的產品規則裡，免費使用者全體共用一個「每天 131,071 次」的池子。這個數字比 Cloudflare 免費方案的每天 10 萬個請求還大。看起來矛盾，其實是兩個層級：

• 131,071／日 是我自己訂的產品上限，管的是「我發出去的每一把 key 能拉多少」。
• 10 萬／日 是 Cloudflare 對我這個帳號的限制，管的是「我的 Worker 被呼叫幾次」。

前者不是從後者算出來的。真正該注意的是：如果全體免費使用者的用量真的把 131,071 那條線跑滿，那 Workers 那一側早就先撞到 10 萬了（除非中間有快取吸收掉一部分）。

也就是說——免費池名目上的天花板，實際上是由平台的額度決定的，不是我自己訂的那個數字。 這也是為什麼要動產品規則之前，得先確認平台那一條線在哪裡。

（順帶一提，131,071 這個數字不是隨便挑的，它跟免費檔其他幾個數字是同一個家族。這個留到 Day 6 講定價的時候一起說。）

撞到牆的時候，第一個要付的錢是每月 $5

規模真的上來，第一個、也是唯一一個要先付的是 Workers Paid：每月 $5，含每個月 1,000 萬個請求。

為什麼「只有這一項」：D1 和 R2 是儲存型服務，可以撐很久才需要往上加；Workers 是「每個請求都算」的服務，它會第一個到頂。

這個級距的意義也順便算一下：

免費方案      100,000 請求/日
付費方案   10,000,000 請求/月 ÷ 30 ≈ 333,333 請求/日

大約是免費方案的 3.3 倍，而且只要 $5。這也是為什麼我把「第一個要付的錢」寫得這麼具體：它不是一筆需要猶豫的支出，是一杯咖啡的價錢換三倍容量。

對照：自己架的話

如果把同樣的東西自己架——一台 VPS 跑 FastAPI、自己裝資料庫、自己掛 CDN——那你從第一個使用者就開始付固定月費，而且付的是「機器」不是「用量」。

兩種模式沒有絕對好壞：自架的天花板高、控制權大、也沒有平台鎖定；免費額度模式的好處是「還沒有人用之前，成本是零」。

對一個人做產品來說，第二種的價值不在省錢，在於它讓我可以先做半年再說。 我不用在還沒驗證需求的時候，就先為一個假設中的流量付錢。

誠實的代價（兩個）

第一，我的 API 入口綁在單一平台上。 免費額度不是沒有代價的，便宜跟鎖定是同一件事的兩面。

第二，這個「免費」只涵蓋分發層。 採集機的月租（人民幣 50～100 元）是從第一天就要付的固定成本——因為它不對外提供服務，也就換不到任何免費額度。整條鏈路不是 $0，是「貴的那一半剛好可以免費」。 這句話我後來在算定價時又想起一次。

明天

額度表裡有一格是 D1 的 5GB，而 D1 就是 SQLite。明天（Day 4）來講為什麼我沒有選 PostgreSQL——以及什麼情況下我會後悔這個決定。